Hi everyone,
This is probably more rant-like than it's supposed to be, and maybe a
bit philosophical, especially after I ran my mouth in the jump
optimisation issue.
So I'm wondering what the future will be for this directive, since it
seems to be very divisive. On one side, its use is questionable with
proposals for 'auto-inline', while on the other side some live by it for
minor performance gains. There's always going to be unexpected uses for
things, and one point of contention that was recently raised is the way
I used it on a function that I knew was only called in one particular
place and would stay that way for the forseeable future. Though I wrote
a comment to explain what I did, apparently that's not a valid reason or
use for it.
I guess that's also an interesting argument in terms of purity of
purpose... do you go by what something was designed to do or what it
actually can do? There's an argument for both - the approach of purity
yields cleaner code but it might suffer with performance, and the
approach of practicality is potentially more efficient, but may be much
more difficult to maintain.
Granted, regardless of one's stance, one does have to abide by a
project's coding standards, even if they are a little nebulous sometimes
and one doesn't often know what they are until they're violated. I
apologise for getting so upset over the presence of a handful of
directives in my patch - to explain, there were a couple of new methods
related to my jump optimisations that were marked as inline (so long as
DEBUG_JUMP wasn't defined) - each function was only called in exactly
one location with no intention of calling them elsewhere. It was set up
this way to compartmentalise the code, separating the jump optimisations
from the main loop of the Peephole Optimizer. Florian took issue with
the inline directives despite the comments explaining why they were
there, since it wasn't exactly to the spirit of what inline is used for
(leaf functions that compile into only a few machine code
instructions). I wasn't too happy about the argument that one of the
functions MAY get called a second time in the future - possibly, but you
can remove the inline directive when that time comes (they'd be looking
up the function header at the very least to see what the parameters are).
I guess sometimes, especially when you've worked on some closed-source
applications, you come across the occasional 'black magic' (for a good
real-world example, look up "fast inverse square root") that takes a
University thesis to explain! Depending on where you work, some are
quite strict with coding standards and how many changes you squeeze into
a single commit, while others a bit more cavalier... which leads to the
minefield that's legacy code! For me personally, I've always pushed for
performance, hence why I have no problem dropping into assembly language
on some critical leaf functions, but I do want to go out of my way to
explain what I'm doing so another programmer can follow what's happening
and improve on it if needs be.
To go back to the original subject, what are the intentions with inline?
I've gotten the impression from Florian that he doesn't like the
directive and would much rather leave it to the compiler to auto-inline
short functions, which I guess is fair, and can potentially make better
judgement calls on a per-platform basis (e.g. vector addition on AMD64
platforms collapses into a single line of machine code (not counting
memory moving), whereas a platform that doesn't have vector registers
may end up with something much longer). As for my example,
auto-inlining a long function that only gets called from one location,
that is certainly possible if functions are reference-counted, but
something tells me it would require whole-program optimisation,
especially if said function is public (or protected).
I don't trust a compiler to produce the most optimal code, whether it be
Free Pascal, Delphi or a C++ compiler, and if I am greatly concerned
about execution speed, I look at the disassembly (I am aware that most
mainstream programmers don't do this). In most cases, it's inefficient
high-level code that simple refactoring can fix (to use an exaggerated
example, changing a sorting algorithm to use quicksort instead of
bubblesort), while other times there is little you can do from the code
alone. I do try to help the compiler though by giving hints like the
inline directive. To branch into a semi-related issue of the compiler
deciding what's best... when I get pure functions working, one could
argue that the compiler should be smart enough to determine if a
function is pure or not, and hence would have no need for a 'pure'
directive - this is true, but would also be prohibitively slow, since
the compiler would be analysing every node in every function with a fine
tooth-comb. That is partly my concern with auto-inline as well...
though there's an upper limit on the number of nodes before it decides
to not inline it, it still has to analyse the nodes one-by-one, and even
counting them requires iterating through what is effectively a linked list.
I know originally that one of Turbo Pascal's selling points was the
speed of its compiler compared to other compilers of the day. I don't
know if compilation speed is in Free Pascal's manifesto, but I like to
think it is, hence my acceptance of compiler hints like 'inline',
whereas auto- features and anything requiring whole program optimisation
(even though that's a Release Build thing) are anything but fast.
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 get working (at least I've struggled). Shouldn't the
compiler have an option to do the two stages of whole program
optimisation (generate the information files, then use the information
files) in one sitting? It would take a long time to complete, but
advertising it as a Release Build thing should prevent most people from
running it accidentally. I personally like seeing file sizes drop and
execution speed climb in my compiled binaries!
Gareth aka. Kit
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
